Suggest using a more rigorous domain validation method.

def is_valid_startup_types(data):
    if not isinstance(data, dict):
        raise TypeError("Data must be a dict")

    if len(data) == 0:
        raise ConfigurationError("Received an empty dictionary for startup types")

    for key, value in data.items():
        if not isinstance(key, str):
            raise TypeError("key must be a str")

        if not isinstance(value, int):
            raise TypeError("value must be an int")

    # Values must be unique, as they correspond to different startup types
    if len(data.values()) > len(set(data.values())):
        raise ConfigurationError("Startup time for two or more startup types is the same.")

    # Return a dictionary after sorting based on values
    return dict(sorted(data.items(), key=lambda item: item[1]))

You can use this domain validator as:

ConfigValue(domain=is_valid_startup_types, doc="...")

This way, you don't have to check for empty dictionaries in your main code.

I have updated the codes based on your comments.

You can use the above domain validator: is_valid_startup_types

With the domain validator, empty dictionaries are no longer valid inputs. You just need to check that it is not None. For improved code readability, I suggest:

if startup_transition_time is None:
    return

You can remove this if condition and de-indent the code.

Domain validator returns a sorted dictionary. So, this check can now be removed.

This check is not needed. If the argument value is None, then Pyomo's ConfigDict would not call the domain validator.

Minor change: For better code readability, please change the condition to if self.config.startup_types is not None:. Also, please remove the comment, as it is no longer applicable (may create confusion for future maintainers).

Done

As mentioned earlier, the if condition check is now unnecessary. You can remove the check, and remove the additional indentation.

Done

Based on your tests, I'm wondering if we should change this to if len(data) <= 1:. This method must be used only when there is more than one startup type. If you have only startup type, then this feels unnecessary (Also, we will have to check the minimum uptime and startup time values to make sure they are consistent). Thoughts?

Yes, I think the suggestion makes sense to me. Eq. 54 in Ben's paper once confused me until I asked for clarification from him. If {"hot": 4, "warm": 8, "cold": 12}, when the downtime is between 4 to 8, it is a hot start; 8 to 12, warm start and 12 to infinity, a cold start. This is important to understand eq54, if only one startup_transition_time is given, eq54 will break down.
I will add this example to the comments.